Re: LISTEN / NOTIFY performance in 8.3 - Mailing list pgsql-performance

From Joel Stevenson
Subject Re: LISTEN / NOTIFY performance in 8.3
Date
Msg-id p0624080ec3e8ade18d73@[192.168.0.9]
Whole thread Raw
In response to LISTEN / NOTIFY performance in 8.3  (Joel Stevenson <joelstevenson@mac.com>)
Responses Re: LISTEN / NOTIFY performance in 8.3  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
>Also, it might be worth enabling log_lock_waits to see if the slow
>notifies are due to having to wait on some lock or other.

Turning on log_lock_waits shows that there is a lot of waiting for
locks on the pg_listener table ala:

process 22791 still waiting for ExclusiveLock on relation 2614 of
database 16387 after 992.397 ms
...
process 22791 acquired ExclusiveLock on relation 2614 of database
16387 after 1433.152 ms

deadlock_timeout is left at the default 1s setting.

Though these are being generated during application activity -
running the simulation script does produce 300ms - 600ms NOTIFY
statements but doesn't (at the moment) trigger a lock_wait log entry.

pgsql-performance by date:

Previous
From: Matthew
Date:
Subject: Re: Q on views and performance
Next
From: Joel Stevenson
Date:
Subject: Re: LISTEN / NOTIFY performance in 8.3